1. Field of the Invention
The present invention relates generally to voicemail provided over the public switched telephone network, and more particularly, to a system and method for analyzing signaling messages for inter-switch voicemail trouble conditions.
2. Background of the Invention
Inter-switch voicemail (ISVM) enables multiple central offices to communicate with multiple voicemail platforms through a single end office. In requiring only the single end office, inter-switch voicemail makes highly efficient use of network resources, especially in comparison to the early generation voicemail systems that dedicated end offices to supporting only one voicemail platform. Unfortunately, along with providing the increased capacity, inter-switch voicemail introduces significant complexities to the call flow and message waiting indicator signaling. These complexities can make troubleshooting inter-switch voicemail systems extremely challenging.
FIG. 1 illustrates a simple example of a conventional inter-switch voicemail architecture. As shown, the architecture includes a voicemail end office 100 in communication with multiple voicemail platforms (VMPs) 102 through multi-line hunt groups 104 and Simplified Message Desk Interface (SMDI) links 106. Voicemail end office 100 is also in communication with end offices 108A-D through trunk groups 110A-D and with signal transfer point (STP) 112 through a Signaling System 7 (SS7) link 113. Signal transfer point 112 is also in communication with end offices 108A-D through SS7 links 114A-D.
Although FIG. 1 shows only one signal transfer point 112, one of ordinary skill in the art would appreciate that multiple signal transfer points could be used to provide a desired redundancy.
To illustrate a typical call flow, FIG. 1 shows a calling party 116 calling a called party 118. End office 108A serves calling party 116, while end office 108D serves called party 118. Assuming that a trunk line 120 connects end office 108A to end office 108D, the call would set up according to normal SS7 processing, including an initial address message, an answer message, a release, a release complete, and then voice path assurance.
With the call set-up complete, if called party 118 does not answer or is already on the line, then the end office 108D that serves called party 118 redirects the call through trunk line 110D and end office 100 to the appropriate voicemail platform 102. If called party 118 does not answer, this call redirect is generally referred to as “call-forwarding don't answer.” If called party 118 is already on the line, this call redirect is generally referred to as “call-forwarding busy line.”
After voicemail platform 102 plays a greeting and records a message from calling party 116, voicemail platform 102 must activate a message waiting indicator (MWI) on the telephone of called party 118, to notify called party 118 that she has a saved message. Thus, voicemail platform 102 sends a message to voicemail end office 100 through SMDI link 106. Voicemail platform 102 transmits the message using Inter-switch Simplified Message Desk Interface (ISMDI), which is a signaling interface used by voicemail platforms to support incoming call and message waiting integration between all supported switches in a Local Access and Transport Area (LATA). Simplified Message Desk Interface (SMDI) defines signaling between a messaging system and a central office switch, which defines the original intended destination of a forwarded call. The ISMDI MWI message sent by voicemail platform 102 references the telephone number of called party 118.
After receiving the ISMDI MWI message, voicemail end office 100 determines if it “owns” (i.e., is associated with) the NPA/NXX (NPA—Numbering Plan Area/NXX—a specific central office) corresponding to the telephone number of called party 118. Assuming that voicemail end office 100 does not own the telephone number, voicemail end office 100 forwards an MWI message through SS7 link 113 and to signal transfer point 112 using a non-call-associated Signaling System 7 (SS7) signaling protocol, such as Transaction Capability Application Part (TCAP).
Signal transfer point 112 contains a database that cross-references NPA/NXXs with the network point codes of end offices. Thus, based on the telephone number referenced in the MWI message, signal transfer point 112 determines to which end office 108A-D the MWI message should be forwarded. With this routing information, signal transfer point 112 transmits a TCAP message to the end office corresponding to the telephone number of called party 118, which in this case is end office 108D connected through SS7 link 114D. End office 108D then activates the message waiting indicator on the telephone of called party 118.
After called party 118 retrieves the message, voicemail platform 102 sends another MWI message through signal transfer point 112 to clear the message waiting indicator at the telephone of called party 118.
As evident from FIG. 1, the multiple links and end offices of the typical ISVM architecture can make it difficult to troubleshoot signaling problems. Examples of common signaling problems include tasks refused, unassigned numbers, incorrect or missing routing, and missing customer records.
As an example of a task refused error, signal transfer point 112 may deliver an MWI message to end office 108D, which then refuses to pass the message to the telephone of called party 118. A common reason for refusing the task is that end office 108D is in the process of performing a back-up. Another possible reason is a translation error in the switch, which is referred to as a “split” when the switch is a Lucent 5ESS™ switch. A translation error could be caused by, for example, a corrupt database in the switch that does not properly relate the call features of a customer to the customer's telephone number.
Unassigned numbers are not assigned in the switch, and are, for example, ported out erroneously to another switch, such as a competitive carrier switch. In this case, when end offices 108A-D receive an MWI message for an unassigned number, the switches simply ignores the MWI message.
Misrouted MWI messages can occur, for example, when one or more signal transfer points of several redundant signal transfer points contain faulty routing translations. In this situation, the signal transfer points that contain correct routing translations route MWI messages to the appropriate end offices, while the signal transfer points that contain faulty translations route the MWI message to incorrect end offices. These incorrect end offices simply ignore the MWI messages, leaving no record by which to troubleshoot the problem.
A no routing error is another common problem. In this case, a mismatch exists between the NPA/NXX records of the voicemail platform and the NPA/NXX records of the signal transfer point or end office. For example, when a new NPA/NXX is opened in the voicemail platform, there may be a lag before the corresponding routing is opened in the signal transfer point and/or end office.
As another common problem, sometimes the voicemail platform may be missing customer records. In this case, the voicemail platform fails to recognize the called party's telephone number and does not send the MWI message at all.
Because of the many possible errors, identifying the source of a voicemail problem can be particularly frustrating. In addition, the idiosyncrasies of the hardware can compound the problem by remaining silent when errors occur. Indeed, it is common for switches, signal transfer points, and voicemail platforms to simply ignore errors, remain silent, and fail to report or record any problem.
To gain a better understanding of error conditions, telephone service providers focus on the signaling portion of the public switched telephone network, and analyze portions of the SS7 protocol that carry ISVM information. This ISVM information is extremely valuable in resolving trouble reported by end-user telephone subscribers who are having voicemail problems.
The analysis of the SS7 protocol is usually left to troubleshooting experts, who sift through call records and spot error patterns that provide clues as to the sources of the problems. Unfortunately, this process is exceedingly time-consuming. The expert must analyze large volumes of call records to identify the intermittent problems among the majority of normal call flows.
Thus, there remains a need for a tool that assists in the detection, diagnosis, and resolution of inter-switch voicemail trouble.